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ABSTRACT 

This  thesis  examines  the  various  functional  modules  that 
have  beer,  designed  in  support  of  ths  Stock  Point  Logistics 
Integrated  Com  minications  Environment  (SPLICE)  local 
computer  network.  Initially,  the  overall  design  methodology 
is  presented,  followed  by  a  description  of  the  functional 
molules,  their  proposed  capabilities  and  their  relationships 
to  each  ether.  Finally,  an  analysis  is  made  to  determine  how 
well  the  modules  fit  together  to  form  an  operational  local 
computer  network  and  to  support  both  inter-  and  intra- 
net work  communications. 
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I.  I»TROD0CTI0» 

A.   GENERAL  OVERVIEW 

The  information  contained  in  this  section  was  obtained 
from  a  series  of  reference  documents  produced  by  both  Naval 
Supply  Systems  Command  (N&VSUPI  ani  Fleet  Material  Support 
Office  (FMSO)  and  is  inclaied  as  background  [Refs.  1,2,3  ]. 

The  Stock  Point  Logistics  Integrated  Communications 
Environment  (SPLICE)  project  is  being  developed  to  augment 
the  existing  Navy  stock  Point  an!  Inventory  Control  Point 
ADP  facilities  that  support  the  Jniform  Alternated  Data 
Processing  System-Stock  Points  (UADP5-SP) . 

Presently,  there  ace  twenty  new  applications  systems  in 
various  stages  of  development  which  will  reguirs  a  consider- 
able amount  of  interactive  processing  and  telecommunications 
support.  The  current  0&DPS-SP  hardware  is  a  Burroughs 
Medium  Size  (B-3  500/3700/47  00/'4  800)  System,  which  will  not 
be  able  to  support  these  requirements  without  a  total  rede- 
sign effort  and  possible  mainframe  replacement.  To  support 
the  interactive  and  telecommunications  capabilities 
required,  individual  project  managers  for  the  new  applica- 
tions systems  development  will  be  itiiizing  a  variety  of 
minicomputers.  These  systams  will  aLl  be  implemented  within 
the  next  four  to  five  years  according  to  projected 
schedules. 

The  development  of  SPLICE  will  lave  two  major  impacts. 
It  will  meet  the  increased  need  for  the  use  of  CRT  display 
terminals  to  interact  with  application  logic  and  retrieve 
information  from  the  system  data  base  and  it  will  also 
address  the  need  for  a  standard  teleprocessing  hardware  and 
software  environment  to   sapport  the  many  new   projects  that 


will  impact  all  Navy  UADP3-SP  sites.  This  standardization 
will  provide  major  economic  benefits  in  the  stages  of 
design,  development,  operation  aid  maintenance  which  will 
occur  at  approximately  sixty  geographically  distributed 
sites,  each  having  a  different  mix  of  application  and 
terminal  requirements. 

At  this  time,  the  SPLICE  processors  are  planned  to  be 
co-located  with  the  hos-  Burroughs  Medium  System  at  each 
Stock  Point  (SP)  activity  and  with  the  Burroughs  and  Univac 
systems  at  the  Inventory  Control  Points  (ICP's).  The  SPLICE 
project  proposes  a  distinct  division  of  processing  responsi- 
bilities called  a  "foreground/background"  concept.  The 
SPLICE  foreground,  utilizing  a  standard  minicomputer  hard- 
ware and  software  set,  will  serve  as  a  front-end  processor 
for  the  Burroughs  system  via  a  Local  Area  Network  (LAN) 
interface  and  will  handle  communication  lines  as  well  as 
support  the  interactive  operations.  This  interactive  trans- 
action processing  support  will  be  accomplished  using  the 
Terminal  Applications  Processing  System  (TAPS)  data  ccmmuni- 
cacion  terminal  management  for  both  on-line  and  host 
processing  terminals,  and  networking  communication  logic  for 
Navy-wide  distributed  and  satellite  activity  capabili-y.  On 
the  host  background  processor  (initially  the  Burroughs 
Medium  Sys-em  computers  at  each  Stoct  Point),  the  functions 
performed  will  include  large  volune  updating  of  master 
files,  creating  hard  copy  reports  and  other  functions  not 
requiring  interactive  immediate  response  access. 

B.   THESIS  OBJECTIVES 

A  portion  of  the  SPLICE  project  was  initiated  at  nhe 
Naval  Postgraduate  School,  Monterey,  California,  at  the 
request  of  FMSO,  to  develop  and  design  suggested 
alternatives  for  SPLICE  Local  Area  Networks.   The  purpose  of 
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this  thesis  is  to  examine  these  alternate  design  specifica- 
tions and  indicate  what  integration  considerations  have  been 
met  and  those  areas  that  remain  to  be  addressed  among  The 
various  functional  modules  that  hive  been  developed  in 
support  of  both  intranetwor k  communications  occurring  within 
the  LAN  itself  and  internetwork  comn unications  between  the 
LAN  and  the  Defense  Data  Network  (See  Appendix  Z    ) . 

C.   BACKGROUND 

The  implementation  of  SPLICE  as  proposed  by  NAVSU? 
reflects  a  tightly  coupled  architecture  which  utilizes  a 
centralized  "complex  manager"  concept.  The  complex  manager 
performs  all  required  coordination  between  the  SPLICE  system 
components,  or  functions.  Eight  of  these  software  functions 
have  beer,  identified  for  development  to  support  the  SPLICE 
concept.  These  functions  ire  lerminil  Managemen t,  Terminal 
Applications,  Data  Set  Management,  Peripheral  Management, 
Batch  Applications,  Complex  Management,  Stock  Point 
Front-End  Processor  Support  and  Stock  Point  Host-Resident 
Support.  The  first  six  functions  will  provide  an  applica-r 
tion  independent  environment  for  LAN  processing,  while  the 
last  two  support  the  Stock  Point  Host  interface  for 
foreground/background  coramunici tion.  It  should  be  noted  here 
that  the  entire  SPLICE  design,  as  outlined  in  the  SPLICE 
System  Specifications  [Ref.  2]  and  the  SPLICE  Software 
Design  [Ref.  1]  revolves  iround  a  predetermined  desire  to 
use  the  Terminal  Applications  Processing  System  (TAPS), 
which  is  currently  in  existence  it  various  Navy  Stock 
Points.  TAPS  is  designed  to  provide  Communications 
Management  (CM)  ,  Application  Management  (AM)  and  Data 
Management  (DM)  capabilities  necessary  for  the  Navy  applica- 
tion systems  to  support  on-line  interactive  query  and  update 
processing  on  the  foreground  complsx. 
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The  alternate  SPLI3E  functional  design  approach  taken 
here  at  the  Naval  Postgraduate  SohDol  is  directed  towards 
designing  the  logical  or  virtual  Local  Area  Nstwork  first, 
thus  ensuring  that  functional  requirements  are  satisfied 
[Rsf.  U].  This  is  accomplished  through  the  development  of 
Functional  Modules  and  their  characteristics  and  the  deter- 
mination of  communication  protocols  necessary  to  support 
them.  The  need  for  a  complex  manager  is  eliminated  by 
providing  the  necessary  control  structures  for  a  fully 
distributed  LAN.  The  ability  to  mcve  a  functional  module 
from  one  functional  nsde  to  another  will  provide  higher 
system  availability  than  in  the  cas=  of  fixed  assignment  of 
functional  modules  to  physical  nodes.  Through  the  proper 
distribution  of  functional  resources  across  the  nodes  of  the 
LAN,  the  failure  of  any  on=  node  would  be  transparent  to  the 
user  and  a  higher  degrse  of  overall  LAN  reliability  is 
provided  than  would  exist  with  th=  use  of  a  centralized 
complex  manager. 
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II.     LOCAL    AREA    NETWORK    AND    FONCriDNAL    MODULE    OVERVIEW 

A.       LOCAL    AREA    NETWORK    (LAN)     DESIGN 

A  LAN  has  been  defined  as  a  data  communication  network, 
typically  a  packet  conn inica tin n  network,  limited  in 
geographical   scope   [Ref.    5]. 

Basically,  local  area  letw^rks  provide  for  the  intercon- 
nection of  data  processing  and  computing  devices  located 
within      a   limited      geographical    area.  They   are      primarily 

aimed  at  providing  a  communications  means  foe  processes 
resident  in  the  multiple  hosts  which  connect  to  the  network. 
LANs  have  been  installed  and  implemented  in  various  forms 
for  a  multitude  of  functions,  and  have  experienced  varying 
degrees    cf   success   [Refs.    5,7]. 

Due  to  the  future  increases  of  oomputing  devices  at  the 
Navy's  Supply  Points  and  Inventory  Control  Points, 
networking  of  the  devices  within  the  local  area  offers  the 
potential  to  efficiently  share  available  resources.  A  local 
network  structure  capable  of  providing  compatible  intercon- 
nection of  various  terminals,  data  processing  devices,  word 
processors,  gateways  to  other  computer  networks  and  of 
virtually  any  type  of  digital  communication  device,  can 
provide  an  extremely  flexible  and  highly  reliable  environ- 
ment   for    SPLICE    configurations. 

A  major  advantage  of  local  area  networks  in  general  is 
that,  once  implemented,  the  local  area  network  can  support 
practically  any  type  of  system  transition.  Another  signifi- 
cant aspect  of  a  well-designed  local  network  is  that  it  can 
support    a   long-term,    vendor-independent    transition    strategy. 
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Local  networks  do  cr=ite  certain  problems  that  must  be 
considered,  however.  Provisions  must  be  mala  for  speed 
matching  between  the  local  area  network  and  the  long-haul 
network.  In  this  particular  instance,  this  matching  mas: 
occur  between  the  SPLICE  LAN  and  the  DDN.  It  can  reasonably 
be  presumed  that  the  LAN  will  have  a  much  higher  data  rata 
than  the  DDN.  Thus,  whan  a  large  number  of  packets  are  sent 
into  the  LAN  to  reach  their  ultimata  destination  through  the 
DDN,  packets  may  arrive  at  the  gateway  much  faster  than  the 
gateway  is  able  to  pass  them  to  the  DDN.  A  mechanism  is 
required  to  prevent  the  gateway  from  exhausting  its  buffer 
space.  Additionally,  the  virtual  circuit  protocol  in  the  LAN 
must  be  compatible  with  that  of  the  DDN  to  allow  for  easy 
translation. 

One  of  the  basic  elements  which  one  must,  consider  when 
dealing  with  LAN  design  is  the  topology  method  used  for 
network  interconnection.  This  issue  is  an  important  one  in 
the  performance  of  the  LAN  and  is  presented  more  fully  in 
the  following  section. 

B.   BUS  TOPOLOGY 

Network  topology  is  the  arrangement  of  digital  devices, 
called  nodes,  relative  to  the  interconnecting  media.  In  the 
recent  evolution  of  local  oomputer  networks,  several  topolo- 
gies have  emerged.  The  SPLICE  reliability  requirements  (as 
outlined  in  the  Functional  Description)  preclude  a  system  in 
which  the  network  can  be  made  inoperative  by  a  single  compo- 
nent failure.  SPLICE  configurations  will  also  be  subject  to 
changes  over  time.  Thus,  SPLICE  requires  a  topology  which 
provides  high  resilience  to  single  oomponent  failure  while 
also  allowing  for  system  growth  and  reconfiguration.  For 
these  reasons,  a  bus  architecture  was  chosen  [Ref.  8]. 
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The   global   bus   configuration   is   an   interconnection 

scieme  in  which  all  network  computers   or  nodes  are  party  to 

a  single  communications  channel  whioh  is  used  in  a  lessag? 
or  packet  switching  mods.  The  channel  may  be  a  single  wire 
pair  or  coaxial  cable  or  even  a  multi-wire  conduit.  All 
node-to-node  communication s  takes  place  ever  this  shared 
channel.  The  channel  operates  in  a  broadcast  multiple  access 
mode,  similar  to  that  of  an  internal  computer  bus,  where  a 
transmission  by  any  of  ti=  nodes  can  be  received  by  ail  of 
the  remaining  nodes  in  the  network.  Access  to  the  channel  is 
controlled  by  any  of  a  nuiber  of  different  time  multiplexing 
schemes.  The  global  bus  topology  for  local  networks  has 
several  inherent  advantages  over  otn  =  r  topologies,  including 
lew  cost  and  ease  of  incremental  network  expansion. 
Throughput  and  message  ieiay  characteristics  are  highly 
dependent  on  the  access  control  protocol  used  [Bef-  9].  la 
this  shared  channel  computer  communication  network,  only  one 
message  can  be  trans  mitten  on  the  channel  at  a  time.  Thus, 
it  must  be  ieter mined  who  can  transmit  at  any  given  time  via 
some  distributed  control  mechanism.  Additionally,  an 
addressing  mechanism  is  require!  to  aid  in  data  flow 
patterns.  As  will  be  seen  in  a  later  fiagram  (Figure  2.1  ), 
the  logical  lesion  of  the  SPLICE  LAS  provides  two  types  of 
buses:  a  data  bus  which  will  transfer  the  actual  applica- 
tions messages  and  a  ccntrcl  bus  which  will  carry 
administrative  traffic  (such  as  resource  allocation  and 
errcr  messages).  Few  local  networks  available  from  vendors, 
however,  provide  secarats  data  and  control  buses  due  to  the 
additional  cost  and  hardware  require!.  Thus,  physical  imple- 
mentation of  this  design  will  utilize  one  bus  [Hef.  4  ]• 
This  physical  configuration  can  be  seen  in  Figure  2.2  . 
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C.   FUNCTIONAL  MODULES 

A  functional  module  is  define!  is  one  which  provides  a 
generalized  function  far  nany  applications.  is  opposed  to 
having  many  sets  of  applications  modules,  there  will  exist 
one  set  cf  functional  mod.il  es  which  can  provide  services  for 
many  applications.  This  design  methodology  was  chosen  to 
save  time  and  money  in  system  development  and  implementation 
[Ref.  10].  Since  many  functions  are  common  to  various 
applications,  a  great  deal  of  duplicate  work  in  the  areas  of 
system  analysis,  design,  programming,  coding,  testing  and 
maintenance  will  result  if  applications  modules  are  designed 
and  implemented  for  each  and  every  application.  The  func- 
tional module  approach  will  eliminate  this  redundancy  and 
alsc  result  in  the  better  utilization  of  computer  resources, 
primarily  memory  and  file  storage  space.  This  last  benefit 
is  due  to  the  fact  that  the  major  differences  in  applica- 
tions usually  exist  in  the  input  and  output  formats  and 
applications  parameters;  they  are  not  normally  in  the  basic 
operations  of  editing  data,  maintaining  files  aid  generating 
displays  and  reports. 

In  the  Postgraduate  School  design  of  the  LAN,  the  gener- 
alized approach  using  functional  modiies  is  emphasized.  Pen 
functional  modules  have  oeen  identified  to  date,  although 
not  ail  have  been  completely  designed.  They  are  listed  in 
Table  I  . 

These  modules  are  divided  into  two  basic  categories: 
operating  functions  such  as  the  transaction  processing 
modules,  and  support  functions  which  are  those  that  exist  to 
ma^e  effective  use  of  the  processing  nodules  and  the  entire 
LAN.  Figure  2.1  illustrates  the  logical  connections  as  envi- 
sioned in  the  SPLICE  LAN  design.  The  actual  configuration 
is  envisioned  as  being  similar  to  that  shown  in  Figure  2.2  . 
It  illustrates  a  LAN  configuration  utilizing  three 
minicomputers  in  addition  to  the  mainframes  at  SPLICE  sites. 
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TABLE    I 
Functional    Modules 


Local   Communications 
National   Communications 
Front-End  Processing 
Terminal    Management 
Data   Base   Management 
Session    Services 
Peripheral   Management 
Security 

Recovery    Manaaement 
Network   Management 


Following    is      an    over/lew   of      the    modules    and      the    basic 
services    -hey    perform.  The    major    modules   and      their    rela- 

tionship  to      other    modules      will    be      discussed   in      detail   in 
Chapters    III   and  IV. 

1 •      Local   Co mmunicatioa s 

-  Bus    arbitration    (traffic    management) 

Message      transmission      and        reception      including      buffer 
management 

-  Message   control    (error    ietection,       correction    and    acknowl- 
edgement) 

-  Administration    (including    message    accounting,      handling    of 
lost    or    misdirected    messages   and    LAN    shutdown) 

2.      National   Communications 

-  Conversion      of   the   Defense      Data    network    protocols      to    LAN 
protocols    and   the  reverse 

-  Message   assembly    and   disassembly 
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Figure  2.  1    Local  Network  Logical  Connections. 
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3-      l£2J£zIS.J  P  rocessing 

-  Terminal   and    communication   line   buffering 

-  Code   Conversion 

-  3yte/vord  assembly    and    disassembly 

-  Control    message  processing 

-  Authentication 

^  •      Terminal    Management 

-  Message   editing 

-  Screen    management 

-  Virtual   terminal    operations 

5»      Data   Base  Management 

-  File  creation    and    updating 

-  Query    processing    and  data    retrieval 

-  Data    dictionary  creation    and    maintenance 

-  File   catalog   creation    and    maintenance 

6  •      Session    Services 

-  Establish   and    maintain    local    and    ranote    sessions: 

a.  Within    the   LAN     (SPLICE   minicomputer    processes) 

b.  With    local   host  (s)     (the    nainframe   processes) 

c.  With   remote    host(s)     (also    mainframe    processes) 

-  Provide  logical  and  physical  network  addresses  based  on 
value    of   a    Services    Reguest    Code 

-  Access    control 

"7.      Peripheral   M  ana  gen  ant 

-  Management  of  Unit  Record  Input/Dutput  (to  include  reading 
cards,  printing  lines,  and  spooling  files  for  input  and 
output) 

-  Dptical   Character    Recognition   or  !1ar!c    Sense    Equipment 
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8 .   Security 

-  Provide  positive  user  identification  via  passwords 

-  Control  authorization  verification 

-  Provide  for  reconstruction  of  critical  data 

-  Provide  auditing  facilities 

9-      Recovery.   Management 

-  Receive  and  react  to  notification  of  transmission  errors 
(existence    of  an    error  conlition) 

-  Maintain  LAN  ccpy  of  Network  Directory  and  update  it  when 
physical    address   changes    occur 

-  Notify  the  Network  Management  noiule  and  all  functional 
modules  and  processors  within  tha  LAN  of  changes  in  LAN 
status. 

10.       Network  Management 

-  Perform   monitoring   and   measuring   of    LAN   performance 

-  Evaluate  network  performance  and  identify  down  or  failing 
com  ponents 

-  Monitor  and  control  LAN  interface  to  long-haul  network 
(DDN) 

Regulate  flow  of  packsts  between.  networks  and  perform 
ether   tasks   to    support    this    flow 

Provide  local  failure  notification  to  nodes  and  hosts 
outside  of  LAN  and  provide  LAN  with  information  about 
outside    nodes   and  hosts 

Provide        accounting        capabilities         (i.e.,  resource 

utilization) 
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III.  COM MUNICir IONS  FUNCTIONAL  MODULES 

A.   NATIONAL  COM MONICATION  (NC)  MODULE 

It  is  a  common  user  requirement  that  a  single  terminal 
ani  access  port  should  be  able  tD  access  any  computing 
resource  that  the  user  may  desire  --  aven  if  ths  resource  is 
on  another  data  network.  Based  on  this  requirement,  there 
arises  a  user  need  to  have  data  networks  connected  together. 
Although  from  user  viewpoints  the  requirement  for  intercon- 
nection is  independent  of  the  network  technology,  this  is 
not  true  from  the  implementation  viewpoints.  There  are  some 
considerable  complications  in  connecting  networks  of  rela- 
tively different  technologies.  These  interconnections  can  be 
vi=wed  primarily  in  terns  of  interfaces  and  network  services 
[Ref.  11]. 

These  can  both  be  divided  on  the  basis  of  the  character- 
istics they  possess  -  those  of  datagram  or  those  of  virtual 
circuit.  It  is  important  to  distinguish  datagram  and 
virtual  circuit  services  from  datagram  and  virtual  circuit 
interfaces. 

1  -   Datagram /Virtual  2112^11 

A  datagram  interface  allows  the  subscriber  to  enter 
packets  into  the  network  independent  of  any  other  packets 
which  have  been  or  will  be  entered.  Each  packet  is  handled 
separately  by  the  network.  A  virtual  circuit  interface 
requires  an  exchange  of  control  information  between  the 
subscriber  and  the  network  for  the  purpose  of  setting  up 
address  translation  tables,  setting  up  routes  or  preallo- 
cating  resources,  before  any  data  packets  are  carried  to  the 
destination.  Thus,  an  and-to-end  logic  circuit  must  be 
established. 
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A  datagram  service  is  one  in  which  each  packer  is 
accepted  and  treated  by  the  network  independently  of  all 
others.  Sequenced  delivery  is  not.  guaranteed.  In  fact,  there 
is  no  guarantee  that  all  datagrams  will  be  delivered.  Since 
packets  may  be  independently  routed  :ver  alternate  network 
paths,  duplicate  copies  of  datagrams  might  be  delivered.  A 
virtual  circuit  service  tries  to  guarantee  the  sequenced 
delivery  of  the  packets  associated  with  the  same  virtual 
circuit.  It  typically  provides  the  host  with  advice  from  the 
network  on  flow  control  per  virtual  circuit  as  opposed  to 
the  packet-by-packet  acceptance  or  rejection  typical  of  a 
datagram  service.  Any  duplicate  packets  produced  are 
filtered  by  the  destination  packet  switch  before  delivery  to 
the  subscriber. 

2.   Oeeration 

The  N3  module  of  the  local  network  provides  the 
interface  between  the  LAN  and  the  DDN.  In  the  NC  module, 
both  sides  of  this  interface  will  provide  a  virtual  circuit 
service  [Ref.  4].  Packets  will  be  transmitted  on  the  DDN 
backbone,  while  fragments  will  be  transmitted  on  the  LAN.  It 
will  be  the  responsibility  of  the  N3  nodule  to  provide  the 
interface  between  the  DDN  and  each  LAN.  This  will  require 
that  a  conversion  be  provided  between  the  LAN  protocol  and 
TCP,  the  protocol  utilized  by  the  DDN.  (See  Appendix  C  for 
specifics  on  TCP.)  To  avoid  connecting  all  functional 
modules  and  nodes  directly  to  the  DDN,  a  gateway  will  be 
used.  The  fundamental  role  of  a  gateway  is  to  terminate  the 
internal  protocols  of  each  network  cd  which  it  is  attached 
while,  at  the  same  time,  provide  a  common  ground  across 
which  data  from  one  network  can  pass  into  another  [Ref.  5  ]- 
The  NC  module  will  function  as  the  gateway  and  contain  both 
the    TCP    and    LAN    protocols. 
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Messages  from  the  D DN  in  the  form  of  packets  accumu- 
late at  the  NC.  The  message  or  fragment  (if  the  NC  has  found 
it  necessary  to  perforn  fragmentation  on  the  incoming 
message)  is  then  sent  to  the  destination  module  over  the 
LAN.  The  destination  module's  logical  address  and  its  phys- 
ical address  would  have  been  recorded  in  the  message  (see 
Session  Services  Module)  at  the  originating  LAN  [Ref.  10]. 

The  task  of  broadcasting  physical  address  changes  to 
the  various  LANs  must  be  accomplished  and  it  is  currently 
envisioned  that  the  Network  Hanagsisnt  Module  located  at 
FMSO  will  handle  this.  Aidit io nally,  each  LAS  must  keep  a 
copy  of  the  network  directory  and  mate  all  necessary  changes 
to  the  network  physical  addresses  as  they  occur.  This  will 
be  done  by  the  resident  Recovery  Management  Moiule  [Ref.  4], 

Physically,  the  NC  resides  in  the  Front-End 
Processor.  It  will  perform  host  to  hcst  flow  control  but  not 
alternate  routing.  Messages  will  be  sent  to  the  nearest 
Packet  Switching  Node  (PSN)  of  the  DDN  on  a  FIFO  basis. 
Since  the  LAN  speed  will  feasibly  be  greater  than  that  of 
the  DDN,  the  NC  buffer  could  easily  fill  to  capacity.  One 
method  of  handling  this  potential  problem  is  to  only  permit 
a  single  message  to  be  unacknowledged  at  a  time  [Ref.  4], 
In  addition,  it  will  necessary  to  reserve  buffer  space  egual 
to  the  maximum  size  message  fragment  that  could  be  received. 
By  utilizing  these  restrictions,  message  handling  will  be 
done  in  a  uniform  fashion  both  intra  LAN  ani  inter  LAN. 
Certain  problems  could  result  froa  the  first  restriction, 
however,  and  these  will  be  discussed  in  the  last  chapter. 

3.   TCP 

As  previously  mentisned,  TCP  is  the  primary 
host-to-host  protocol  in  the  DDN.  Ai  overall  description  of 
TCP       can      be      found      in        A ppendix      Z;         however,         the      key 

characteristics    are    reiterated   here: 
-   Host-to-Host   Protocol 
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-  Resident    in   the  ISO  Transport    Layer 

-  Messages    delivered    in   sequence 

-  Logical    full-duplex  connections 

-  Sequence    number  assigned    to   each   octet 

-  Message   sequencing   and    ao  kr.owledgeaents   controlled    by    time 
outs 

-  Connection   name  used  to  refer    to   connections   after    connec- 
tion   is   established. 

-  Precedence   and   security    of      messages    may   be    established    by 
users 

-  Window    oriented  flow  control 

-  Destination    TCP  reassembles   message    segments 

-  Mandatory    that    acknowledgements  be    sent 

Only  those  aspects  of  the  IC?  which  are  necessary  to 
convert  messages  from  LAN  to  DDN  format  and  vice  versa  will 
be  implemented  in  the  NC.  The  TCP  commands  which  will  be 
implemented   in   the    NC   are    is   follows: 

*  DPEN 

-  Active:  3egin  procedure  to  synchronize  connection 

-  Passive:  Listen  for  an  incoming  signal 

(Respective   modules  will   be  notified   by   their  local   and 
remote  NCs  when  a  connection  his  been  made.) 

*  SEND 

-  send    data      contained   iQ    the   indicated   user      buffer    on   the 
connection    indicated 

*  RECEIVE 

-  allocate  a  receiving  buffer  associated  with  the  specified 
connection 

*  CLOSE 

-  close   the   specified  connection 

(Respective   modules    will   be    notified    by    local    and    remote    NCs 
that    the    connection    is   closed.! 

*  STATUS 

-  obtain  status  of  connection 
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(This  command  is  not  always  implement  ad;   however,   it  would 
be  to  the  advantage  of  the  SPLICE  network  to  utilize  it.) 
*  ABORT 

-  causes  all  pending  SENDs  and  RECEIVES  to  be  aborted.  k 
RESET  message  is  sent  to  the  remote  TCP.  Respective  modules 
are  notified  by  their  local  and  remote  NCs  that  the  connec- 
tion has  been  aborted. 

It  should  be  mentioned  here  that  the  activity  of  the 
TCP  can  be  characterized  as  responding  to  events.  The  events 
mentioned  above  fall  into  the  category  of  user  calls. 
Processing  is  dene  by  the  TCP  in  response  to  each  of  the 
events  that  occur.  In  many  cases,  the  processing  required 
will  depend  on  the  state  of  the  connection. 

U .   Network  Layers 

For  sending  and  receiving  messages  on  the  DDN,  all 
seven  network  layers  as  defined  in  the  Reference  Model  of 
Open  Systems  Interconnection  (3SI)  proposed  by  the 
International  Standards  Organization  (ISO)  [Ref.  12]  will  be 
used.  See  Table  II  .  The  TCP  format  [Ref.  23]  will  be 
provided  to  the  DDN  by  the  NC  moduls  whenever  communication 
on  the  DDN  is  necessary. 

5  •   Addressing 

The  TCP  uses  poet  identifiers  in  its  healer  to  iden- 
tify the  separate  data  streams  that  the  TCP  may  handle. 
Since  port  identifiers  are  selected  independently  by  each 
operating  system,  TCP,  3r  iser,  they  might  not  be  unique  to 
each  TCP.  To  provide  for  unique  addressing  at  each  TCP,  an 
internet  address  identifying  the  TCP  is  concatenated  with  a 
port  identifier  to  create  a  socket  which  will  be  unique 
throughout  all  networks  connected  together  [Ref.  10].  The 
TCPs  are  free  to  associate  ports  with  processes  in  any 
manner  they   choose;   however,    several  basic   concepts  are 
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TABLE    II 
ISO  Layers   ia    DM    Commanication 


Layer 

Appiicat ion 

Presentation 

Session 

Transport 

Network 

Data  Link 

Physical 


Sodule 

Application  process  modules 

Terminal  Management 

Session  Services 

TCP 

to  be  specified  by  the  DDN 

to  be  specified  by  the  DDN 

to  be  specified  by  the  DDN 


necessary.  It  is  envisioned  rhat  processes  may  "own"  ports 
and  that  -hey  can  only  initiate  connections  on  the  ports 
that  they  own.  A  connection  is  spscified  in  the  OPEN  call 
by  the  local  port  and  foreign  (destination  end)  socket  argu- 
ments. After  the  connection  has  been  opened,  the  TC? 
supplies  a  local  connection  name  by  which  the  user  refers  to 
the  connection  in  subsequent  calls  "Ref.  23]. 

In  the  SELICE  LANr  the  port  identifier  will  corre- 
spond to  the  logical  address  of  a  functional  module.  The 
network  address  corresponds  to  that  of  a  physical  processor 
in  which  the  module  resides.  This  will  allow  for  the  flexi- 
bility and  mobility  of  modiles,  since  logical  addresses  do 
net  change,  whereas  physical  addresses  are  subject  to 
change.  Both  types  of  addresses  will  be  necessary  to  access 
a  particular  functional  module  in  the  SPLICE  network. 
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B.   LOCAL  COHHONICATIONS  (LC)  MODULE 

The  LC  module  will  also  use  a  virtual  circuit  service. 
It  will  be  possible  to  set  up  a  virtual  circuit  between  any 
two  modules.  The  circuit  would  be  Implemented  by  creating 
tables  in  the  Session  Services  module  at  both  the  receiving 
and  sending  ends  of  the  connection  [  Ref .  10]-  The  virtual 
circuit  can  be  established  between  two  functional  modules 
residing  in  the  SPLICE  minicomputers  and  also  between  a 
functional  module  residing  in  a  SPLICE  minicomputer  and  a 
functional  module  residing  in  a  main  frame. 

1  •   Network  Lasers 

The  TCP  protocol,  as  it  is  currently  specified,  is 
more  complex  than  necessary  for  use  in  a  local  area  network 
such  as  SPLICE.  In  addition,  measurements  of  the  TCP 
[Ref.  23]  indicate  that  it  has  very  poor  throughput  compared 
tc  a  high  speed  (13 Mbits/se c)  bus  such  as  the  one  proposed 
for  the  SPLICE  lccax  area  network,  ani  thus  will  not  provide 
optimal  local  communication  performance.  If  the  entire  TCP 
were  included  in  LAN  communications,  many  extra  functions 
not  needed  would  be  unnecessarily  implemented.  Thus,  the 
best  approach  seems  to  be  to  utilize  a  subset  of  the  DDN 
virtual  circuit  protocol,  waich  is  as  close  to  TCP  as 
possible,  but  which  specifies  cnlv  those  portions  needed  by 
the  LAN.  In  this  manner,  translation  between  the  two  proto- 
cols is  simplified  and  protocol  compatibility  is  provided 
without  the  necessity  of  designing  t<to  protocols  [Ref.  5]. 

Overall,  a  much  simpler  format,  as  shown  in  Table 
III,  will  be  used  for  intra  Lan  communication  than  that  of 
the  entire  ISO  model.  The  LAN  will  not  require  the  detailed 
services  normally  provided  by  the  Transport  and  Network 
Layers  CRef-  **]<•  The  Presentation  Layer  functions  will  be 
implemented   in  the   Terminal  Management   module.   It   will 
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T&BLE  III 
ISO  Layers  in  LAH  Communication 


Layer  aodule 

Application  Application  process  modules 

Presentation  Terminal  Management 

Session  Session  Services 

Data  Link  Loral  Communications 

Physical  Looal  Communications 


accept  data  from  the  application  process  and  convert  it  to 
the  designed  LAN  standard  format.  It  will  also  accspt  LAM 
formatted  messages  and  convert  than  to  the  appropriate 
application  process  format.  A  terminal  user  would  be 
considered  an  "application  process"  in  this  conversion 
activity. 

The  end-to-end  virtual  circuit  connections  (the 
logical  communication  linkage  between  two  functional 
modules)  and  the  fragmentation  of  complete  messages  can  be 
implemented  in  each  of  tha  functional  modules,  as  opposed  to 
having  them  handled  by  a  Transport  Layer  [Ref.  *].  In  -his 
manner,  a  subset  of  the  D DN  virtjal  circuit  protocol  (TCP) 
would  be  used,  as  previously  descrioed,  and  the  need  for  a 
complete  Transport  Layer  would  be  eliminated. 
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2  •      Addressing 

To  enable  implementation  of  the  architecture  which 
has  been  described,  it  will  require  that  logical  addresses 
be  assigned  to  the  functional  nodules  which  will  be 
contained  within  the  SPLI3E  minicomputers  and  to  the  func- 
tional modules  which  currently  exist  in  the  SP  and  ICP  main 
frames.  This  last  assignment  will  reguire  the  identification 
of  programs  or  packages  In  the  main  framesthat  make  up  a 
functional  module.  The  identification  of  resources  is  a 
central  issue  in  the  development  of  distributed  systems  in 
order  to  provide  location  independence  and  the  possibility 
of  having  multiple  copies  of  the  same  functionally  named 
resource  within  the  LAN  [8ef.  10].  This  location  indepen- 
dence should  permit  end  users  and  applications  proarams  the 
ability  to  access  and  manipulate  data  regardless  of  whether 
it  resides  locally  or  at  another  noie  on  the  LAN  or  at  any 
remote  node  in  the  SPLICE  network.  To  support  this  location 
transparency,  it  will  be  necessary  to  create  and  maintain  a 
table  which  will  provide  tie  physical  address  of  a  hardware 
unit  when  the  logical  address  is  given.  This  table  and  all 
neoessary  maintainance  functions  associated  with  it  will  be 
the  responsibility  of  Session  Services  [Ref.  10].  Althcugn 
a  table  concept  was  originally  developed  for  a  ring  network 
structure  [Ref.  13]  it  can  be  simulated  under  other  network 
architectures,  such  as  Ethernet,  which  also  uses  a  bus 
structure  [Ref-  10]. 

3  •      i5i.ssa.2e    Formats 

LAN  message  foraats  have  been  designed  by  many 
authors.  The  basic  structure  provide!  here  was  designed  in  a 
previous  thesis  [Ref.  8],  however,  additional  features  have 
been  included  to  incorporate  other  functions  performed  by 
the  network  [Ref.  »].   If  other  functions  are  required,  they 


33 


can  be  included  at  a  latar  date  in  much  the  same  manner. 
Whan  a  module  requires  an  acknowledgement,  tha  acknowledge- 
ment will  be  piggybacked  onto  a  data  message  if  data  is 
ready  to  send  to  the  nodule.  if  there  is  no  data  to 
transmit,  an  ordinary  ackn owledgemei t  message  will  be  used. 
Requirements  for  control  must  be  incorporated  into  this 
method.  These  will  allow  for  priority  message  notification 
as  well  as  distinguish  between  new  massages  and  acknowledged 
messages.  It  is  planned  that  massages  will  be  transmitted  in 
one  continuous  stream  of  bits  " Ref .  »  ].  Although  this  will 
simplify  the  communications  protocol,  buffer  space  must  be 
reserved  for  the  maximum  size  message.  To  handle  long 
messages  which  could  exceed  the  maximum  buffer  size  of  a 
functional  module,  fragmentation  is  used  [Ref.  f*].  A  frag- 
ment is  merely  a  part  of  a  message.  In  this  instance, 
identification  numbers  must  be  provided  for  both  messages 
and  for  fragments.  Following  are  illustrations  of  the  intra 
LAN  message  formats  and  descriptions  of  the  packet  format 
fields.  The  data  field  length  is  allied  to  vary.  All  other 
fields  should  be  fixed  length,  however  specific  lengths  for 
th=se  fields  can  be  determined  after  detailed  network 
configurations  and  hardware  specifications  have  been 
established  [Ref.  8]. 

a.   Flag 

The  flag  field  is  a  bit  pattern  which  signifies 
tha  beginning  and  ending  of  a  message  or  message  fragment. 
The  beginning  flag  field  is  also  jsed  to  synchronize  the 
receiving  processsor  with  the  incoming  bit  stream.  This 
pattern  should  be  chosen  =ich  that  its  length  is  sufficient 
for  positive  identification  and  its  distortion  due  to  colli- 
sion with  another  transmitter's  flag  is  easily  discernable 
by  collision  detection  devices.  The  use  of  the  flag  sequence 
is  data  or  control  information  that  occurs  between  flags 
must  be  prevented  through  use  of  a  bit  stuffing  mechanism. 
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Figure  3.1    LAN  Message  Format. 

b.   Message  Type 

This  is   a  code  indicating   the  type   of  message 
being  transmitted.  The  major  message  types  are  as  follows: 

-  Normal    Data 

-  Priority   Data 

-  Ordinary   Acknowledgement 

-  Data    with   Piggybacked    \z knowledgenen t 

-  Reset    LAN    (resets   communications    after    error    condition) 

-  Reset      Message  and     Fragment    Counts       (resets    counters      to 
zero) 

-  LAN    shutdown 
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-    others 

c.  Date   and   Time 

This  provides  the  day,  aonth,  year  and  24-hour 
clock    time    of   message  transmission    from    sender. 

d.  Destination    Address 

This  provides  the  logical  and  physical  address 
of  the  receiving  module.  It  will  iaform  the  correct  moduls 
to  copy  the  rest  of  the  bit  stream  and  continue  processing. 

e.  Source  Address 

This  provides  the  logical  and  physical  address 
of  the  sending  module.  It  is  requirsi  for  propsr  addressing 
of  acknowledgements  ani  zo mmunicatis ns  control  information 
which  must  be  maintained. 

f.  Number    of   Fragments 

This  provides  the  number  of  fragments  contained 

in  a  message.    It  is  usei  primarily  for  message  sequencing 

and  for   acknowledgement  oontrol  and  also  by   the  receiving 
module  for  allocating  buffer  space. 

g.  Message    Number 

This  is  the  sequential  number  assigned  to  each 
transmitted  message.  If  the  message  being  sent  is  an 
acknowledgement,  the  nuaoer  of  the  message  being  acknowl- 
edged would  be  placed  in  this  field.  This  number  is  reset  to 
zero  on  a  periodic  basis.  Each  modile  will  be  responsible 
for  setting,  resetting  and  incrementing  this  count.  In  this 
manner,  the  receiver  will  always  know  which  message  it 
should  next  receive  and  the  sender  fill  know  which  message 
number  should  next  be  acknowledged  by  the  receiver. 
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h.   Fragment  Number 

This  is  a  sequential  number  which  is  assigned  to 
each  fragment  that  belongs  to  a  message.  This  number  will  be 
reset  to  zero  by  the  sender  as  soon  is  the  first  fragment  of 
a  new  message  is  ready  to  be  transmitted.  Each  module  is 
responsible  for  setting,  resetting  and  incrementing  this 
count.  In  this  manner,  the  receiver  will  always  know  which 
fragment  number  it  should  next  receive.  (The  message  number 
will  be  increased  after  ill  fragments  have  been  received.) 
The  sender  will  know  which  fragment  number  should  be  next 
acknowledged  by  the  receiver.  The  first  fragment  will  be 
numbered  zero. 

i.   Acknowiedgemeit  Message  dumber 

This  provides  the  message  number  that  is  being 
acknowledged. 

j.   acknowledgement  Fragment  Number 

This  provides  the  fragment  number  that  is  being 
acknowledged. 

k.   Data  Length 

This  field  provides  the  number  of  bytes  in  the 
data  portion  of  a  message  or  message  fragment.  If  no  data  is 
being    sent,    this    field  oan    have    a    value    of    zero. 

1.      Services    Request    Code 

This  code  will  indicate  which  service  is  being 
requested   by     a    process.  (e.g.      r=trieve      record,      update 

record,    etc.) 
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m.   Data 

The  data  field  contains  the  information  to  be 
delivered  by  the  network.  All  other  portions  of  the  message 
header  are  stripped  from  tie  massage  when  it  arrives  at  tha 
receiving  module. 

n.   Error  Check 

This  field  contains  the  Cyclic  redundancy  Code 
(CRC)  which  is  a  checksum  computed  by  the  sender.  If  an 
error  is  detected  by  the  receiver,  tie  fragment  is  discarded 
by  -he  receiver  and  will  lot  be  acknD wledged.  k  match  indi- 
cates that  there  are  no  errors  and  the  message  will  be 
accepted  by  the  receiver  and  acknowledged.  If  sender  does 
not  receive  an  acknowledgement  after  an  appropriate  amount 
of  time,  it  will  assume  ion-receipt  and  retransmit.  If  the 
second  attempt  at  transmission  fails,  the  Recovery 
Management  module  will  be  notified  of  an  error  condition. 

It  should  be  loted  that  the  Message  Number  and 
Fragment  Number  fields  will  be  used  for  data  messages  and 
foe  non-piggybacked  acknowledgement  messages.  The 
Acknowledgement  Message  tf umber  aid  the  Acknowledgement 
Fragment  Number  fields  are  only  used  when  the  acknowledge- 
ment is  piggybacked  ontD  the  data  being  sent.  The  Data 
Length,  Services  Request  Zode  and  Data  fields  are  only  used 
when  data  is  actually  beiag  transmitted  in  a  message. 
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IV.  MANAGEMENT  AND  CONTROL  FUNCTIONAL  MODULES 

A.   SESSION  SERVICES  (SS)  MODULE 

The  SS  module  provides  the  overall  controlling  mechanism 
among  the  clients  of  the  LAN  functioaal  resources,  i.e.  the 
terminal  user  and  other  functional  resources  themselves. 
Although  the  original  design  of  Session  Services  [ Ref .  10] 
makes  a  distinction  between  Controlling  SS  and 
Non-controlling  SS,  for  tae  sake  of  simplicity  and  to  avoid 
confusion,  this  thesis  will  consider  Session  Services  as  one 
entity  containing  all  described  characteristics.  Regardless 
of  whether  a  process  is  based  on  an  interactive  application 
or  on  an  interactive  session  (via  a  LAN  user's  issuance  of 
guery  language  transactions),  there  nust  exist  a  controlling 
service  to  communicate  aid  control  the  requirements  of  the 
user  process (es)  between  itself  and  the  functional  resources 
of  the  LAN.  In  order  to  establish  communication  between  the 
controlling  mechanism,  the  user  and  the  functional  modules, 
a  simple  request-accept  message  transfer  needs  tc  be 
performed  [Ref.  10].  This  service  request  code  in  a 
message,  similar  to  a  user  request  task,  is  used  by  SS  to 
obtain  -he  logical  and  physical  addresses  of  the  functional 
moduie(s)  which  will  perform  the  caquested  service.  An 
acknowledgement,  indicating  either  acceptance  or  denial  of 
session  support,  would  be  sent  to  tae  requesting  SS  module. 
After  this  series  of  events  has  been  established,  the  user's 
process  can  communicate  freely  throagh  SS  without  the  need 
to  reconstruct  another  session  service.  References  to 
currently  supported  user  sessions  would  be  maintained  in  a 
table  and  could  be  used  to  identify  the  validity  of  client 
access   for  service   by  the   functional   resource.   SS   will 
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invoke  the  appropriate  functional  module  which  then  accesses 
the  user  message  in  the  Terminal  Management  buffer.  The 
moiule  returns  the  required  data  after  interpreting  the 
instructions  in  the  user  message.  It  is  the  responsibility 
of  Terminal  Management  to  present  the  data  provided  by  the 
functional  module  in  the  format  needed  by  the  user  [Hef.  4  ]. 
This  entire  process  involves  all  the  ISO  layers  (as  illus- 
trated in  Figure  III  )  reguired  to  support  intra  LAN 
communications. 

If  certain  reguests  for  service  from  a  user  process 
require  coordination  and  oontroi  of  multiple  LAN  functional 
resources,  Session  Services  will  ensure  that  the  reguest  is 
appropriately  broken  down  into  its  respective  component 
service  reguests  and  that,  they  are  performed  in  the  correct 
order.  Easically,  SS  operates  through  Terminal  Management. 
This  situation  results  from  the  fact  that  user  process 
messages  reside  in  Terminal  Management  during  a  session  and 
it  is  the  responsibility  of  Terminal  Management  to  keep  the 
user  informed  of  all  progress  associated  with  the  processing 
of  his  reguest  [ Ref .  10].  SS  Issues  the  various  messages  to 
the  functional  modules  in  support  of  this  reguest. 

B.   TERMIHAL  MANAGEMENT  (TS)  MODULE 

The  purpose  of  the  rs  module  is  to  provide  LAN  users 
with  the  facilities  for  oo mmun icating  simultaneously  with  a 
large  number  of  processes  spread  out  among  various  systems. 
A  terminal  user  might  need  to  communicate  with  the  LAN  or 
with  other  local  area  networks  (other  Stock  Points)  through 
the  DDN  [Ref.  10].  Since  the  set  of  functional  modules  in 
this  design  approach  eaci  provide  the  same  basic  service, 
the  major  place  where  applications  are  differentiated  is  on 
the  terminal  screen  formats. 
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Terminal  handling  has  always  baen  somewhat  of  a  problem, 
since,  while  terminals  exhibit  rathar  similar  characteris- 
tics, they  can  differ  in  vary  significant  ways.  In  a  network 
architecture,  the  problem  is  additionally  compounded.  Each 
host  must  support  all  n  kinds  of  teriinals  supported  by  each 
of  the  m  hosts  en  the  network.  Thus  each  host  must  poten- 
tially be  able  to  support  a  x  n  tarminals  to  permit  any  usar 
to  connect  to  it.  As  can  easily  ba  seen,  this  is  fairly 
impractical. 

Terminal-oriented  protocols  ara  dasigned  to  reduce  this 
"m  x  n"  problem  to  a  manageable  siza  by  establishing  conven- 
tions for  handling  all  the  terminals  on  the  network 
[Ref.  15].  Ona  such  approach  to  a  tarminal  protocol  defines 
a  network  virtual  terminal  (NVT)  [Ref.  16].  In  this  method, 
tha  source  terminal  sida  of  a  connection  maps  the  output  of 
its  terminal  into  the  NVI  format  for  transmission  through 
the  network.  At  the  destination  tsrninal,  the  ^VT  format  is 
mapped  into  its  local  format  for  presentation.  The  user 
ends,  as  defined  above,  could  be  processes  as  well  as  phys- 
ical terminals.  This  approach  has  tie  advantage  of  avoiding 
the  delays  and  efficiencies  of  attempting  to  synchronously 
share  a  data  structure  across  a  network. 

The  NVT  has  several  shortcomings,  however,  which  must  be 
considered  [Ref.  15].  The  introduction  of  new  terminal 
commands  or  primitives  witacut  modifying  the  protocol  means 
that  each  new  terminal  command  will  require  a  minimum  of  six 
octets  (octet  =  8  bits)  to  be  reprassnted.  3ecause  tha 
protocol  is  stream- oriental ,  every  octet  of  tha  data  stream 
must  be  scanned  to  find  control  sequancas.  Secondly,  for  a 
virtual  terminal  protocol  (VT?|  to  ba  successfully  used  in  a 
general  environment,  the  virtual  tarminal  must  be  very  well 
defined.  Otherwise,  programs  that  ise  the  terminal  in  more 
sophisticated  applications  such  as  iispiaying  and  updating 
fields  on   a  CRT   will  not   be  able   to  format   their  output 
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deterministically  without  considerable  knowledge  of  the 
physical  terminal  being  used  [Ref.  15].  There  is  also  the 
possibility  that  not  all  physical  tsrminais  may  be  aole  to 
service  all  virtual  functions.  Additionally,  for  a  VTP  to 
be  generally  applicable,  it  must  restrict  itself  to  terminal 
funct  ions. 

European  investigations  into  virtual  terminal  protocols 
have  made  two  major  contributions:  (1)  a  well-defined 
virtual  terminal  and  (2)  the  development  of  a  model  for 
attentions  or  interrupts  [Ref.  17].  The  VTP  defines  an 
basic  framework  for  the  virtual  terminal,  and  classes  of 
virtual  terminals  are  defined  that  correspond  to  the  classes 
of  real  terminals  available  (e.g.,  scroll  mode,  paged,  data 
entry,  etc.).  Each  class  uses  the  basic  model  and  adds  to  it 
the  facilities  and  structures  required.  Thus,  the  use  of 
terminal  class  avoids  requiring  taat  all  implementations 
support  the  most  sophisticated  terminal  functions  and  allows 
the  characteristics  of  a  virtual  terminal  to  more  closely 
resemble  the  real  terminal  being  used  [Ref.  17].  The 
European  designs  also  provide  commands  for  one  side  (virtual 
terminal)  to  request  of  the  othsr  what  optioas  and  what 
range  of  parameters  it  supports  and  for  the  requested  side 
to  report  what  it  can  support. 

There  may  be  some  limitations  imposed  on  the  choice  of  a 
virtual  protocol,  however,  as  it  is  currently  planned  for 
the  DDN  to  use  an  ARPANET  Telnet  NVT  feature  [Ref.  22].  In 
this  case,  the  NVT  protocol  will  be  probably  needed  in  the 
TM  module  to  enable  coramuai cation  with  remote  processes  ever 
the  DDN.  A  Terminal  Management  generic  module  has  been 
proposed  [Ref.  18]  which  attempts  to  provide  a  methodology 
for  utilizing  a  VTP  other  than  SVT  and  still  maintain 
compatibility  with  the  DDN  protocol.  It  is  felt  that  this 
proposal  should  be  further  exaaiaed  in  terms  of  its 
suitability  for  the  SPLICE  local  network. 
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C.   DATA  BASE  MANAGEMENT  (DBM)  MOD0LE 

Although  the  LAN  design  provides  for  distributed 
control,  it  does  not  provide  for  tae  total  distribution  of 
data  bases  within  the  LAN.  There  is,  however,  distribution 
between  the  interactive  Data  3ase  Management  System  (DBMS) 
in  the  SPLICE  miniconput er  and  the  Burroughs  mainframe 
batch-oriented  DBMS  [Ref.  4].  Data  bases  are,  of  course, 
distributed  over  the  entire  SPLICE  network.  The  data  base 
functions,  however,  are  centralized  within  each  LAN 
[Ref-  10].  This  will  enable  the  local  network  to  maintain 
the  necessary  control  and  integrity  of  files,  as  the 
catalog,  data  dictionary  and  indices  will  be  centralized. 

As  distributed  processing  systems  continue  to  grow, 
database  management  systems  will  hav=  to  undergo  changes  to 
be  responsive  to  the  special  re guirements  of  the  distributed 
environment.  This  will  be  mcst  evident  in  the  situation  of 
the  local  area  network  [Ref.  19].  changes  will  be  needed 
both  in  the  service  provided  by  database  management  systems 
and  in  the  service  implementation  -  the  way  it  is  packaged 
ana  delivered.  System  resources  oar.not  be  dedicated  to 
single  functional  modules;  for  a  variety  of  reasons, 
inoluding  the  need  to  utilize  oommoa  information,  they  must 
be  shared.  Rothnie  and  others  [Ref.  20]  believe  that  the 
type  of  architecture  provided  by  3DD-1  is  appropriate  for 
activities  reguiring  access  to  a  siigie  pool  of  information 
distributed  over  a  wide  geographical  area.  It  will  permit 
decentralized  processing  for  reasons  of  performance,  reli- 
ability and  flexibility  of  function,  and  was  designed  to 
manage  data  bases  whose  storage  is  distributed  over  a 
network  cf  computers. 

Lowenthal  [Ref.  19]  introduces  the  concept  of  a  file 
server.  This  is  a  special  purpose  software  module  that,  as  a 
minimum,   would  coordinate  concurrent  access  to  a  given  file 
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from  multiple  requestors.  It  :an  also  support  file  sorting, 
catalog  management  and  index  searching.  In  a  DBMS,  the  file 
server  will  handle  the  entire  database  as  well  as  files. 
With  adequate  fixed  disk  storage  foe  highly  active  files  and 
moveable  disk  storage  for  less  active  files,  it  should  be 
capable  of  supporting  foreground  queries  and  file 
maintenance  requests. 

Closely  relating  to  this  concept  is  that  of  the  backend 
database  management  system  as  discussed  by  Maryanski 
[Ref.  21].  This  system  was  originally  proposed  as  a  solu- 
tion to  the  problems  of  overloaded  data  processing 
installations.  Database  management  functions  ace  offloaded 
from  the  existing  mainframe  to  an  attached  minicomputer. 
Basically,  database  requests  are  presented  to  the  DBMS  after 
they  originate  in  an  applications  program  and  are  trans- 
mitted through  the  interface  routines.  When  the  database 
request  has  been  completed,  the  resulting  data  and  status 
information  are  returned  tc  the  backend  interface  which 
initiates  transmission  of  the  results  to  the  host.  This 
method  does  have  the  advantage  of  freeing  a  substantial  part 
of  the  processor's  resources;  howavar,  it  has  a  number  of 
drawbacks  as  well.  A  major  drawback  is  the  performance 
penalty  incurred  by  the  introduction  of  the  interface  and 
communication  software  and  the  transmission  time  of  the 
intercomputer  link.  Additionally,  code  conversion  will  be 
required  for  mapping  character  and  integer  data  between 
different  implementations.  3oth  of  the  concepts  presented 
are  worthy  of  further  investigation  as  to  their  applica- 
bility to  the  LAN  design.  A  recommendation  for  a  particular 
type  of  DBMS  has  not  been  made  by  previous  studies  [ Ref s.  4 
,10  ]f  since  it  was  felt  that  stronger  emphasis  should  be 
placed  on  the  capabilities  of  a  venlor  provided  DBMS  (i.e., 
integrity,  recovery,  dictionary,  query  language,  data 
accessability ,  security,   etc.l   ratier  than  on  the  specific 
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model  selected.  Although  a  complete  assign  for  the  database 
functional  module  was  not  developed,  a  number  of  management 
tools  (for  providing  organizational  support)  and  some  of  the 
basic  functions  the  DBMS  should  provide  have  been  identified 
[Refs.  4  ,10  ]  and  these  ace  briefly  discussed  below. 

A  Data  Sub-Language  (DSL)  consists  of  a  Data  Definition 
Language  (DDL)  for  defining  data  objects  (fields)  and  a  Data 
Manipulation  Language  (DML)  for  the  processing  of  data 
objects.  As  identified  by  the  CODASZL  group,  the  main  func- 
tion of  DDL  is  to  describe  the  content  and  structure  of  the 
database  schema  and  subschema.  Althoagh  all  DBMS  have  a  DDL, 
these  can  vary  in  the  extent  to  whioh  complex  relationships 
can  be  expressed.  The  complexity  and  capabilities  of  the  DDL 
should  be  worth  careful  consideration  based  on  its  applica- 
tion by  Navy  Stock  Points  and  Inventory  Control  Points.  The 
DMLs  are  used  to  transfer  data  to  and  from  the  database. 
They  can  be  accessed  by  calls  from  a  procedural  language. 
The  capabilities  of  the  DML  will  directly  affect  the  appli- 
cations programmer.  Since  the  DDL  and  DML  are  closely 
related,  the  functionality  of  each  generally  determines  the 
degree  of  responsibility  of  both  the  data  base  administrator 
and  the  applications  programmer. 

Database  Query  Languages  (DQLs)  are  generally  interac- 
tive in  nature.  Often  called  "end-user  facilities,"  DQL 
facilities  provide  direct  interaction  with  the  database 
schema  and  permit  search  strategies  for  data  retrieval  or 
updates  by  approved  end  users  of  the  DBMS.  With  a  user 
friendly  DLQ,  users  can  perform  ad  aoc  queries  or  can  build 
user  command  files  for  repetitive  data  entry,  retrieval  and 
validation.  A  fully  implemented  and  varied  DQL  will  greatly 
support  the  current  and  future  information  requirements 
needed  by  the  Navy  Supply  System. 
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Database  utilities  cover  a  multitude  of  areas,  from 
password  security  to  image  management  software  and  database 
tuning  utilities.  Additional  database  software  for  text  and 
graphic  displays,  audit  trail  utilities,  database  develop- 
ment aids,  database  reloading  and  reorganizing  aids  and 
database  sizing  and  responsiveness  aids  are  also  available. 
These  could  prcve  extremely  useful  in  support  of  LAN 
reguirement  s. 

Data  Dictionaries/Directories  (DD/D)  are  vital  in  a 
distributed  data  environment  and  they  may  be  implemented  in. 
a  variety  of  ways.  A  data  dictionary  is  used  to  identify  and 
define  the  data  elements  contained  in  the  database,  and  any 
relationships  that  may  exist  between  these  data  elements.  It 
indicates  where  data  resides  geographically  and  what  data 
are  replicated.  It  should  tell  who  owns  the  data,  who  are 
responsible  for  the  accuracy  of  the  data,  who  update  data, 
and  who  is  authorized  to  raad  the  iita.  The  data  directory 
may  refer  to  applications  programs,  input  cr  report  docu- 
ments, cr  simply  job  streams,  but  generally  it  supports  the 
use  of  data  elements  that  were  identified  in  the  data 
dictionary. 

The  D3M  module  must  maintain  the  catalog  of  file  names 
and  status  for  files  pertaining  to  the  foreground  applica- 
tions. This  catalog  shouli  include  filename,  size,  physical 
address  of  both  file  and  index,  location  of  backup  copy, 
access  restrictions  and  format.  The  module  should  also  be 
able  to  retrieve  records  for  display,  change  records,  delete 
and  insert  records  and  print  both  records  and  entire  files. 
When  printing  a  record,  the  TS  molula  will  route  the  trans- 
action message  tc  the  D3!l  module.  This  module  will  locate 
and  retrieve  the  record  and  send  it  to  the  Peripheral 
Management  (PM)  module  for  printing.  If  a  user  desires  to 
print  a  file,  the  D5M  module  will  have  to  open  the  file  for 
the  PM  mcdule.   The  PM  module  will  then  access  and  spool  the 
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file  onto  its  own  disk  file.  It  oan  then  print  the  fila 
without  tying  up  the  rest  of  the  L^N  operations  [Ref.  4  ]. 

Capabilities  should  exist  to  prevent  data  integrity 
problems  when  multiple  processes  read  or  update  the  same 
data.  The  system  should  also  permit  the  use  of  high-level 
database  user  languages  for  lata  retrieval,  report 
formatting  and  searching  for  and  updating  the  data. 

Although  the  above  suggestions  io  aot  cover  every  aspect 
of  a  DBMS  components  and  functions,  they  do  describe  the 
types  of  facilities  and  capabilities  which  must  be  consid- 
ered in  providing  a  completely  distributed  processing  systei 
for  the  LAN. 


4* 


v-  CONCLUSIONS  AND  RECOBHENDATIONS 

It  is  felt  that  the  overall  design  of  the  LAN  in  terms 
of  the  functional  modules  presented  provides  a  qualitative 
and  useable  design  effort  for  a  distributed  Local  Area 
Network.  A  number  of  issies  still  remain  to  be  addressed, 
however,  to  insure  that  all  functions  have  been  completely 
considered  and  developed. 

-  Continued  support  of  organizational  needs  is  paramount  in 
the  design  of  any  LAN.  If  LAN  operability  can  be  terminated 
by  the  failure  of  any  single  node  (functional  module),  than 
the  LAN  has  the  potential  to  be  highly  unreliable.  Some 
effort  should  be  expended  on  providing  dependability  through 
a  method  for  duplication  of  critical  data  and  critical 
functions  throughout  the  L\N. 

-  More  effort  should  be  ievoted  to  the  development  of  the 
DBM  module  and  the  DBMS.  Careful  consideration  of  the  inter- 
relationships between  the  Stock  Points  and  the  Inventory 
Control  Points  should  be  made  in  ths  selection  of  any  DBMS 
to  support  long  range  organizational  objectives. 

-  Additional  research  should  be  performed  in  the  areas  of 
security  and  in  the  management  of  functional  shared 
resources.  The  provision  of  security  controls  that  are  tamp- 
erproof  may  best  be  accomplished  by  designing  them  into  the 
hardware.  -  Although  the  ooncept  of  having  only  one  message 
outstanding  at  a  time  between  a  pair  of  functional  modules 
on  the  LAN  provides  certain  advantages  (i. e. , reduced  buffer 
size  requirements),  there  can  be  a  significant  drawback  as 
well.  Since  a  monumental  share  of  the  communications  will 
be  occuring  between  the  Front-End  Processor  and  the  Terminal 
Management  and  Session  Services  modules  due  to  the  physical 
connections   envisioned  (see   Figure   2.2   ),   it   is   quite 
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feasible  that  this  restriction  on  window  size  for  the 
various  modules  could  create  a  backlog  of  messages  for  the 
bus.  It  is  recommended  that  additional  study  be  done  to 
determine  whether  or  not  it  would  be  more  efficient  and 
productive  to  increase  the  suggested  window  size  and  allow 
more  than  one  unacknowledged  message  to  exist  at  a  given 
time. 

-  Backup  and  recovery  are  very  important  in  support  of 
the  SPLICE  requirement.  Additional  study  should  be  performed 
in  these  areas  and  a  working  Recovery  management  module 
should  be  developed  to  :iandle  error  detection  within  the 
LAN. 

A  Security  Management  module  should  be  developed  after 
the  appropriate  appropriate  risk  analysis  has  been  performed 
to  provide  for  the  important  considerations  of  security  and 
privacy  needed  in  a  distributed  system. 

-  A  design  for  a  Frsat-End  Processor  should  be  initi- 
ated. It  is  suggested  that  a  programmable  front-end 
processor  would  be  more  cost  effective  in  communications 
control  and  would  provide  more  flexible  solutions  to 
changing  communications  requirements. 

A  menu  for  dialogues  should  be  incorporated  into 
Session  Services  to  enable  users  to  more  easily  employ 
distant  databases,  making  inquiries,  searching  the  data, 
generating  reports,  and,  where  desirable,  updating  and 
creating  data. 

-  A  Peripheral  Management  module  should  be  developed  to 
meet  the  need  for  unit  record  input  md  output  control.  This 
functional  module  will  enable  users  to  print  lines,  have 
cards  read  and  spool  files  for  input  and  output.  Thorough 
research  should  be  done  to  determine  what  specific  require- 
ments may  be  required  to  a eet  currant  and  future  needs  of 
the  Stock  Points  and  Inventory  Control  Points. 
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-  A  simulation  model  should  be  designed  to  estimate  tha 
performance  of  the  LAN  as  designed.  Attention  should  be 
particularly  focused  towards  response  time  and  message 
transit    time. 
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APPENDIX    A 
ACRONYMS 

ACK  Acknowledgement 

AM  Application   Management 

ARPANET  Advanced        Research  Projects        Agency 

Network 

BBN  Bolt    3iranek    and    Newman 

CRC  Cyclical   Redundancy    Check 

CRT  Cathode    Ray    Tube 

CM  Commuii cations    Management 

DARPA  Defense        idvanced         Research        Projects 

Agency 

DBM  Data  Base  Management 

DBMS  Data  Base  Management  System 

DD/D  Data  Dictionary/Directory 

DDL  Data  Definition  Language 

DM  Data  Management 

DML  Data  Manipulation  Language 

DOD  Department  of  Defense 

DSL  Data  Sib-Language 

FD  Functional  Description 

FEP  Front-end  Processor 

FMSO  Fleet  Material  Support  Office 
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IM?  Interface  Message  Processor 

I?  Internet  Protocol 

IPLI  Internet  Private  Line  Interface 

LC  Local  Z ommunications 

NAVSUP  Navy  Sipply  Systems  Command 

NC  National  Communications 

NM  Network  Management 

NVT  Network  Virtual  Terminal 

PM  Peripheral  Management 

RM  Recovery  Managem3nt 

SM  Security  Management 

SP  Stock  Point 

SPLICE  Stock     Point    Logistics     Integrated 

Communications  Environment 

SS  Systen  Specification 

TAC  Terminal  Access 

TAPS  Terminal  Application  Processing  System 

TCP  Transmission  Control  Protocol 

UADPS-SP  Uniform  Automated  Data  Processing  System 

-  Stock  Point 

VTP  Virtual    Terminal    Protocol 

WIN  WWMCCS    Intercomputer    Network 

WWMCCS  World   tfide   Military      Command    and   Control 

System 
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APPENDIX  B 
DEFENSE  DATA  NET&DRK  I 

The  following  information  is  provided  as  a  short:  summary 
of  the  Defense  Data  Network  (DDN) .  rhe  source  document  used 
is  the  Defense  Data  Network  Progran  Plan  revised  May  1982 
[Raf.  22]. 

A.   GENERAL  DESCRIPTION 

The  DDN  is  designed  to  be  a  single  integrated  packet- 
switching  data  network  which  nests  DOD  data  network 
requirements,  both  present  and  planaed.  The  DDN  takes  full 
advantage  of  existing  operational  networks,  such  as  the 
WWMCCS  Intercomputer  Network  (SIN)  aid  the  Advanced  Research 
Projects  Agency  Network  (ARPANET),  for  hardware,  software, 
operations  and  maintenance  procedures  adaptation.  Its  design 
will  be  based  primarily  on  ARPANET  technology. 

To  reduce  development,  maintenance  and  logistical 
support  costs,  it  is  planned  to  standardize  components  to 
the  maximum  extent  possible.  These  components  are  switching 
node  hardware,  switching  node  software,  cryptographic 
devices,  mini-TACs,  host  front-end  devices,  host  interface 
devices  and  multiplexers. 

The  switching  node  is  a  3olt  Baranek  and  Newman  (B3N) 
C/30,  which  is  a  microprogrammed  minicomputer  that  can 
include  TEMPEST/HEMP  protection.  This  is  the  most  current 
generation  cf  packet  switching  hardware  using  the  Interface 
Message  Processor  (IMP)  software.  The  C/30  is  designed  for 
unattended  operation  and  requires  no  dedicated  personnel. 
DDN  will  have  171  switching  nodes  located  at  approximately 
85   geographically   distributed  sites.     These   nodes   will 
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reside  on  military  facilities  and  are  secure  to  a  minimum 
level  of  SECRET.  The  DDN  will  contain  a  number  of  network 
Monitoring  Centers  (MCs) :  a  principle  System  &z ,  an  alter- 
nate HC,  regional  MCs  in  the  Pacific  and  in  Europe,  and  MCs 
at  each  keyed  community.  The  33s  monitor  the  network 
status,  provide  for  fault  isolation  and  diagnosis,  support 
software  maintenance  in  the  nodes  and  mini-TACs,  and 
maintain  network  elements  information. 

The  network  is  designed  to  minimize  communications 
errors  through  the  use  of  error  detection  and  correction 
mechanisms.  A  Cyclical  Redundancy  Check  (CRC)  of  15  bits  is 
associated  with  host  messages  on  the  access  line  and  with 
paokets  on  trunks  to  haidle  burst  errors  that  typically 
occur.  In  addition,  16-bit  checksums  are  provided  en  an 
end-to-end  basis  within  the  switch  subnetwork  and  on  a 
user-to-user  basis  via  the  Transmission  Control  Protocol 
(T3P)  .  The  protection  mechanisms  used  in  the  switches  are 
error  detection  and  correction  hardware  to  protect  against 
meaory  failure  and  checksum ming  of  critical  data  structures 
and  portions  of  code. 

An  availability  of  at  least  99£  will  be  provided  by  the 
network  to  any  pair  of  single-homed  users  that  wish  to 
communicate  with  each  other.  Jsers  will  have  the  capability 
to  enhance  their  availability  either  by  dual  access  (two 
access  lines  to  the  same  switching  node)  or  Dy  dual-homing 
(a  single  access  line  to  two  switching  nodes).  The  latter 
method  provides  an  increased  network  availability  of  99.95* 
and  will  be  used  for  critical  subscribers. 

Originating  hosts  and  terminals  can  assign  traffic 
precedence  levels  which  will  then  be  used  by  the  switching 
nodes  and  mini-TACs  as  a  criterion  in  resource  allocation. 
The  switching  nodes  provide  four  levels  of  precedence, 
preemption  of  lower  precedence  connections,  non-blocking  of 
host   input  and   reservatisn  of   buffers   and  other   traffic 
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related  data  structures.  The  mini-TAC  provides  four  levels 
of  precedence,  preemption  of  input  I3P  segments  and  reserva- 
tion of  input  buffers.  Catsgory  I  (FLa=h  and  Flash  Override) 
traffic  has  the  highest  precedsnce  level  and  will  be 
processed  in  a  non-blocki ng  node  exclusive  of  all  other 
traffic   modes   and  volumes. 

A  number  of  features  are  provided  by  DDN  to  ensure  its 
survivability.  All  DDN  hardware  will  have  HEMP  projection 
in  the  form  of  EM  shielding,  line  isolation  and  surge 
arresting  protection.  Uninterruptibl5  power  supplies  will  be 
provided  to  those  selected  sites  having  no  backup  power.  To 
facilitate  system  reconstit ution,  there  will  be  five  mobile 
reconstitution  nodes  equipped  with  MC  capabilities.  DDN 
utilizes  a  dynamically  adaptive  routing  algorithm  to  auto- 
matically route  traffic  around  congested,  damaged  or 
destroyed  switches  and  trunks  so  the  system  can  continue  to 
function.  There  is  also  a  dense  trunking  grid  to  provide 
redundancy   at   all  possible    points   in    the   network. 

B.       SECURITY    AND    PRIVACY    MEASURES 

1  •      kLZkk   Encryption 

The  K3-8U  crypto  device  is  used  on  ail  backbone 
trunks,  on  all  access  lines  to  classified  hosts  and 
mini-TACs,  and  on  access  Lines  to  sites  that  act  as  MCs  for 
the  unclassified  community.  The  link  encryption  provides 
full  period  traffic  flow  security  protection  by  concealing 
traffic  patterns  of  interswitch  traffic,  and  by  concealing 
subnet  monitoring  reports,  which  coild  reveal  traffic  anal- 
ysis information.  It  will  also  protect  MC-switch  control 
traffic  from  disclosure.  Traffic  *hich  is  sent  from  one 
remote  host  to  another  remote  host  is  encrypted  first  by  the 
Internet  Private  Line  Interface  (IPLI)  and  again  by  the 
KG-84     (see    Figure  B.1). 
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Figure  B.1    End-to-End  Encryption, 
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2«   Security  Level  Sep a  ration 

All  DDN  subscribers  will  operate  at  a  specified 
system  high  security  level.  Separation  of  subscribers  at 
different  levels  is  provided  by  the  use  of  IPLIs.  Thus  there 
will  be  at  least  on  IPLI  Ic  ey  for  each  different  system  high 
level,  and,  at  minimum,  one  such  logical  subnet  for  each 
security  level.  The  IP  and  subnet  headers  must  be  in  the 
clear  for  packet  processing  within  the  switch,  yet  they 
provide  information  about  subscriber  traffic  patterns  and 
traffic  analysis  information  is  classified  secret..  This 
problem  is  handled  by  link  encryption  of  subscriber  access 
lines  and  by  ensuring  that  all  switching  nodes  are  TEMPEST 
enclosed  and  in  secure  military  facilities.  To  prevent 
misdelivery  of  traffic  statistics  by  the  subnet,  each  MC  and 
tha  "fake"  host  in  each  switch  that  communicates  with  the  HC 
will  be  members  of  a  logical  subnet  that  includes  only  these 
members.  The  reguests  from  the  SC  that  trigger  collection 
and  reporting  of  traffic  statistics  will  be  protected  using 
a  cryptographic  authentication  protocol. 

3.   SeDaraticn  of  Communities  of  Interest 

Communities  of  interest  are  subscriber  groups  which 
1)  present  an  acceptable  level  of  risk  to  each  other  and  2) 
require  a  high  level  of  interoperability.  Separation  of 
communities  of  interest  is  accomplisi ed  through  the  creation 
of  logical  subnets  by  cryptographic  means,  by  software 
control,  or  both.  For  unclassified  subscribers,  the  switches 
provide  the  ability  to  define  logical  subnets  which  confine 
traffic  flow  only  to  the  memDers  of  that  logical  subnet. 
These  logical  subnets  are  established  by  the  SMC.  Currently 
the  switches  allow  for  up  t o  16  suca  subnets,  but  this  can 
be  easily  increased  tc  32  or  6*. 
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Rigorous  separation  for   classified  user  communities 
is  provided  by  IPLIs.    As  mentioned  earlier,   there  will  be 
at  least   one  IPLI  subnet   (collection  of   like-keyed  IPLIs) 
for   each  security   level.   At   this  time,    a  community   of 
interest  is  limited  by  policy  to  128  subscribers. 

*•   Individual  Access  Z ontrol 

Access  control  to  subscribsrs  facilities  is  the 
responsibility  of  the  subscribers  taemselves.  The  network 
will  assure,  based  on  a  number  cf  special  mechanisms,  that 
the  access  of  one  subscriber  to.  another  is  controlled  with 
respect  to  authorized  security  level  and  community  of 
interest.  Network  facilities  do  not  /erify,  however,  that  an 
individual  user  (person  or  process)  attempting  to  access  a 
subscriber  has  valid  access  rights  to  that  subscriber. 
Access  control  to  mini-IAZs  is  provided  by  physical  access 
control  measures,  as  mini-T&C  access  is  only  available 
through  hardwire  lines. 

5  •   P§£§_onn  e  1  Z  lear  a  nee  Require  mints 

All  personnel  with  access  to  switches  must  be 
cleared  to  secret  level  due  to  the  traffic  analysis  poten- 
tial. This  clearance  level  also  applies  tc  all  personnel  at 
the  SMCs  and  RMCs.  Personnel  maniiig  a  MC  for  a  secure 
subnet  must  be  cleared  to  the  level  of  the  subnet  subscri- 
bers, allowing  personnel  access  to  :hc  corresponding  IPLIs. 
Crypto  technicians  will  be  needed  for  keying  the  IPLIs  for 
each  community  and  for  link  KGs.  The  keying  material  for 
each  IPLI  community  is  available  only  at  the  IPLI  sites.  The 
keying  material  for  the  link  K3s  is  available  on  a  pairwise 
basis  at  the  switch  sites  based  on  switch  connectivitv. 
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C.   MAJOR  HARDWARE  ELEMENTS 

1  ■   Switching  N ode 

The  switching  node  is  a  BBS  C/30  packet  switching 
processor  in  a  TEMPEST/HEMP  package.  The  C/30  hardware  is  a 
multi-board,  microprogrammed  miniconputer  with  64K  words  of 
Random  Access  Memory  (RAM)  .  It  supports  a  fall  range  of 
synchronous  and  asynchronous  I/O  interfaces.  The  C/30  soft- 
ware is  the  ARPANET  Interface  Massage  Processor  (IMP) 
program.  IMP  software  can  be  loaded  locally  (from  a 
cassette)  or  by  a  downline  load  unier  MC  control.  The  soft- 
ware provides  four  major  finctional  capabilities:  1)  Tandem 
(store  and  forward)  traffic  processing  2)  Host  access  and 
end-to  end  traffic  processing,  using  a  variety  cf  host 
access  protocols  3)  Routing  via  a  dynamic,  adaptive 
distributed  routing  algorithm  that  measures  actual  packet 
delays  and  routes  individual  packets  along  the  least  delay 
path    4)  Monitoring  and  control  services. 

2-   Internet  Private  Line  LULiLli-- 

The  IPLI  is  a  security  device,  currently  under 
development,  which  supports  the  DOD  standard  IP  protocol  and 
provides  end-to-end  encryption.  IPLI  is  composed  cf  three 
functional  units:  a  KG  34  cryptographic  device  and  two 
MC68000  based  packet  processors  (one  on  the  red  side  and  one 
on  the  black  side  of  the  K2  84»  .  Two  hardware  interfaces  are 
provided  on  each  side  of  the  IPLI.  Initially  used  for  backup 
purposes,  they  will  later  provide  for  dual-homing 
Topologies. 

The  software  in  each  processor  will  be  based  on  the 
CMOS  operating  system  being  used  foe  a  variety  cf  packet- 
switching  applications.  It  will  have  the  basic  functions 
necessary  for  the  DOD  standard  internet  environment  and  for 
monitoring  and  control.   T3 P  and  other  protocols  which  exist 


55 


above  the  IMP  can  be  supported  sines  the  IPLI  has  no  knowl- 
edge of  the  TCP  and  packet  processing  occurring  at  ths 
Internet  Protocol  lower  lsvel. 

3 .   M^ni-T AC 

A  mini-TAC  is  a  terminal  accsss  device  that  allows  a 
cluster  of  up  to  16  synchronous  and  asynchronous  terminals 
to  access  the  network.  It  is  logically  equivalent  to  a 
network  host,  particularly  in  that  it  uses  ths  same  host- 
host  protocols.  A  mini-TAC  will  bs  constructed  around  a 
Motorola  MC68000  microprocs ssor  with  memory,  16  synchronous 
or  asynchronous  terminal  ports  and  aultiple  network  inter- 
face ports.  The  mini-TAC  will  aeet  TEMPEST  and  HEMP 
requirements. 

The  mini-TAC  software  allows  terminal  users  to 
establish  connections  between  their  terminals  and  an  arbi- 
trary host  on  the  network.  The  software  will  multiplex  all 
of  the  terminal-host  connections  ovsr  a  single  TAC-IMP 
access  line.  Mini-TACs  will  communicate  with  other  network 
hosts  using  the  DOD  standard  TCP  and  IP.  The  Telnet  protocol 
will    be   used   to    provide   terminal   levsl    support. 

The  mini-IACs  will  be  designsd  for  unattended  opera- 
tion and  will  require  no  dedicated  personnel.  Ail  control 
functions  and  hardware  aid  software  fault  diagnosis  can  be 
done    remotely    from    the   network   Monitoring    Centers. 


57 


APPENDIX    C 
TRANSMISSION    CONTROL    PROTOCOL 

This  appendix  presents  a  simple  description  of  the 
Transmission  Control  Protocol.  The  information  provided  was 
obtained  from  the  DARPA  Transmission  Control  Protocol  docu- 
ment   of    January    1980    [Ref.    23]. 

A.  GENERAL 

The  Transmission  Control  Protocol  (TCP)  is  intended  for 
use  as  a  highly  reliable  standard  fov  the  transmission  and 
reception  of  messages  between  host  computers  in  a  packet 
switched  computer  communications  environment.  This  internet- 
work environment  consists  of  hosts  connected  to  networks 
which   are   in   turn  intercom ected    via    gateways. 

TCP  is  a  connection-orients!,  end-to-end  reliable 
protocol  designed  to  fit  into  a  layers!  hierarchy  of  proto- 
cols which  support  multi  network  applications.  It  provides 
for  reliable  inter-process  communication  between  pairs  of 
processes  in  host  computers  attached  to  distinct  but  inter- 
connected computer  communications  networks.  The  TCP  fits 
into  a  layered  protocol  architecture  just  above  a  basic 
Internet  Protocol  (IP)  which  provides  a  way  for  the  TCP  to 
send  and  receive  blocks  of  data,  called  datagrams,  through 
multiple  networks  and  interconnecting  gateways.  (See  Figure 
C.1)  . 

B.  BASIC    FDNCTIONS 

Since  the  primary  purpose  of  TCP  is  to  provide  reliable, 
securable  and  logical  circuit  or  connection  service  between 
pairs    of    processes    the   following    facilities   are    ceguired: 
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Figure   C.  1         Protocol   Layering. 

1-  Basic  Data  Transfer 

By  packaging  some  number  of  :ct=is  into  segments  for 
transmission  through  the  internet  system,  the  rCP  is  able  to 
transfer  a  continuous  stream  of  octets  in  each  direction 
between  its  users.  The  decision  to  block  or  forward  data  is 
made  by  the  TCP  at  its  own  convenience.  Usees  are  also 
allowed  to  submit  records,  called  letters,  for  transmission. 
In  this  case,  the  TCPs  will  forwari  and  deliver  data  up  to 
the  record  boundary  (end-o f-lettec)  that  was  specified  by 
the  sending  user. 

2-  Reliability 

The  TCP  must  be  able  to  recover  when  data  is 
damaged,  lost,  duplicated  or  delivered  out  of  order  by  the 
internet  communications  system.  To  accomplish  this,  each 
octet  transmitted  is  assigned  a  sequence  number,  and  a  posi- 
tive acknowledgement   (ACKl   is  reguired  from   the  receiving 
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TCP    within     a   specified    time   interval.  if   tha    ACK      is    not 

received,    data   is  retransmitted. 

The  sequence  numbers  are  used  by  tha  receiver  to 
correctly  order  segments  arriving  out  of  order  and  to  elimi- 
nate duplicates.  A  checksum  is  added  to  each  segment 
transmitted  to  deal  with  damage  occurrance.  This  checksum  is 
verified  at  receiving  end  and  all  damaged  segments  are 
discarded.  If  the  internet  system  does  not  become  completely 
partitioned,  properly  functioning  reps  will  be  able  to 
recover   from   internet   communication    system    errors. 

3 •      Flow   Control 

The  receiver  can  govern  the  amount  of  data  sent  by 
the  sender  by  returning  a  "window"  with  every  ACK  indicating 
a  range  of  acceptable  sequence  numbers  beyond  that  of  the 
last  successfully  received  segment.  In  stream  mode,  the 
window  indicates  the  number  of  allocable  octets  the  sender 
may  transmit  before  further  permission  must  be  obtained.  In 
record  mode,  the  window  tells  the  allowed  amount  of  buffer 
space   the   sender   may    consume. 

^  •      Multip_i  e  xing 

The  TCP  provides  a  set  of  addresses  or  ports  within 
each  host  to  permit  many  processes  within  that  host  to  use 
TCP      ccmmunicaticn      facilities    simultaneously.  These      are 

concatenated  with  the  network  and  aost  addresses  from  the 
internet  communication  layer  and  fori  a  socket.  Each  connec- 
tion is  uniquely  identified  by  a  pair  of  sockets,  so  one 
socket   may   be   used    in   multiple   connections. 

The  connection  of  ports  to  processes  is  indepen- 
dently handled  by  each  host,  however  it  proves  useful  to 
attach  frequently  used  processes  to  fixed  sockets  and  make 
these  addresses  known  to  users.  Dhise  services  can  then  be 
accessed   more   easily. 
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5.   Connections 

TCPs  are  required  by  both  tie  reliability  and  flow 
control  mechanisms  to  initialize  and  maintain  certain  status 
information  for  each  data  stream.  The  combination  of  this 
information,  which  incluies  sockets,  sequence  numbers  and 
window  sizes,  is  called  a  connection.  The  pair  of  sockets 
that,  identifies  its  t»3  sides  uniquely  specifies  a 
connection. 

If  two  processes  wish  to  communicate,  their  TCPs 
must  first  establish  a  connection.  This  is  accomplished 
through  the  initialization  of  the  status  information  on  each 
side.  When  the  communication  is  complete,  the  connection  is 
terminated  or  closed  to  free  the  resources  for  other  users. 
Since  these  connections  nast  be  established  between  hosts 
over  a  somewhat  unreliable  internet  oommunication  system,  a 
handshake  mechanism  with  clock-bassd  sequence  numbers  is 
used  to  avoid  erroneous  initialization  of  connections. 

6  •   ?I§ceden ce  and  Secarity 

The  users  of  TC?  may  indicate  the  security  and 
precedence  of  their  communication.  Since  not  all  TCP 
modules  will  necessarily  function  in  a  multilevel  secure 
environment,  some  may  ba  limited  to  unclassified  use  only 
and  others  may  operate  at  only  one  security  level. 
Provision  is  made  for  default  values  to  be  used  when  these 
features  are  not  needed. 

C.   MODEL  OF  OPEBATION 

Processes  transmit  lata  by  caLling  on  the  TCP  and 
passing  buffers  of  data  as  arguments.  The  TCP  packages  the 
data  from  these  buffers  into  segments  and  calls  on  the 
internet  module  to  transmit  each  segment  to  the  destination 
TCP.   The  receiving  TCP  places  the   lata  from  a  segment  into 
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the  receiving  user's  buffer  and  notifies  the  receiving  user. 
Control  information  is  included  in  the  segments  used  by  the 
TCPs  to  insure  reliable  ordered  data  transmission . 

Each  TCP  has  an  internet  protocol  module  associated  with 
it  to  provide  an  interface  to  the  local  network.  This 
internet  module  packages  T3P  segments  inside  internet  data- 
grams and  routes  these  datagrams  to  a  destination  internet 
module  or  intermediate  gateway.  To  transmit  the  datagram 
through  the  local  network,  it  is  eabedded  in  a  local  network 
packet.  The  packet  switches  may  perform  further  packaging, 
fragmentation  or  other  operations  to  achieve  the  delivery  of 
the  local  packet  to  the  destination  internet  module. 

At  a  gateway  between  networks,  the  internet  datagram  is 
"unwrapped"  from  its  local  packet  aid  examined  to  determine 
through  which  network  the  internet  datagram  will  travel 
next.  The  internet  datagram  is  thai  "rewrapped"  in  a  local 
packet  suitable  to  the  next  network  and  routed  to  the  next 
gateway,  or  to  the  final  destination. 

A  gateway  can  break  up  an  internet  datagram  into  smalier 
internet  datagram  fragments  if  needed  to  allow  transmission 
through  the  next  network.  To  accomplish  this,  the  gateway 
produces  a  set  of  internet  datagrans,  each  of  which  contains 
a  fragment  of  the  original.  These  fragments  nay  be  broken 
down  again  at  intermediate  gateways.  The  fragment  format  is 
designed  so  that  the  destination  internet  module  can  reas- 
semble these  fragments  into  internet  datagrams.  A 
destination  module  unwraps  the  segient  from  the  datagram 
(after  fragments  have  been  reassembled,  if  necessary)  and 
passes  it  to  the  destination  TCP. 

It  should  be  noted  that  the  mechanisms  of  TCP  do  not 
preclude  implementation  of  the  TCP  in  a  front-end  processor, 
however,  in  such  a  case  a  host-to-front-end  protocol  must 
provide  the  functionality  to  support  the  type  of  TCP-user 
interface  reguired. 
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